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DISCLOSURE TEXT: 

Disclosed is a method that allows on-line (electronic) purchase 
and delivery of (both electronic and physical) goods in a manner that 
preserves anonymity of the consumer. The method is secure and 
resistant to cheating by both consumers and merchants. 
The following notation is used throughout this document. 

C,M - Consumer and Merchant, the protocol participants; 

ID-x - user ID of X; 

PK-x - Public Key of X (X=C or X=M); 

SK-x - Secret/Private Key of X (X=C or X=M); 

Rc/Rd - Random numbers (nonces) 

Cert-x - Public Key Certificate of X; includes PK-x 

H(text) - Strong one-way Hash function computed over "text", e.g., 
Secure Hash Function (SHA) or MD5. 



Sx(text)- Signature computed under SKx, Sx text =SK-x(H(text)) 
[text] - Optional text 

Prerequisites for the present method are the possibility of 
anonymous communication (e.g., (1) and a public key infrastructure 
(for merchants only). The buying process is started by a sender, 
usually a prospective consumer, who composes an offer request with a 
plaintext (unencrypted) description of the desired product or service 
and a random quantity H(Rc). This construction does not by itself 
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reveal the sender's identity. 

The resultant offer request is sent anonymously to one or more 
selected merchant(s), or even broadcasted, via the network. 
If a 

merchant decides to make an offer, he/she composes a reply with an 
offer description and his/her digital signature (SIG_offer), which is 
computed over the sender's random quantity H(Rc), and transmits it 
back to the sender. The merchant's public key may also have to be 
transmitted since in some cases the sender does not yet have it. 

Upon receiving the message, the consumer can (if necessary) 
extract the merchant's public key and verify the merchant's SIG_offer 
computed over (among other values) the consumer's H(Rc). 

The present method commences when the consumer decides to 
purchase the aforementioned merchandise based on a previous 
bid/offer. The payment process itself is outside the scope of this 
document. 

(See (2) or (3) for examples of secure electronic payment 
protocols and scenarios.) 

Assume that the payment process takes place before the delivery 
of goods (although it can, in principle, take place concurrently.) 
Step 1 . 

a) (note: Consumer is assumed to retain Rc and SIG_offerfrom 
above.) Consumer generates another random number Rd and 
computes H(Rd). 

b) Optionally, consumer generates a public/private key-pair 
(PKtmp,SKtmp). 

(This key-pair is to be used for the delivery 
of 

goods later.) 

c) Consumer sends to merchant a COMMIT_REQUEST message 
containing: 

H(Rc), H(Rd), Captions 
where H(Rc), H(Rd) are as described above and "C_options" are 
optional parameters including, for example: date/time-stamp, 
PKtmp, mailing address (for off-line, non-electronic goods), etc. 
Step 2. 

a) Merchant receives the COMMITJREQUEST and extracts both H(Rc) 
and H(Rd). H(Rd) is stored for future reference. 

b) Using H(Rc) merchant searches his records and checks if the 
corresponding bid/offer has been processed. 

If the offer is no 

longer valid, merchant sends and error message to consumer and 
terminates processing. 
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c) If the offer is still valid, merchant composes and send to 
consumer a COMMIT message containing: 
SKm COMMIT_REQUEST, M_options , M_options 

\ / 

SIG_commit 

where SIG_commit represents a merchant's signature computed 
with SKm over the specified data. "M_options" are optional 
parameters. 
Step 3. 



a) Consumer receives the OFFER message and (using merchant's public 
key PKm) verifies SIG_commit. If the signature is invalid, an 
error message to that effect is sent to merchant, 
b) If signature is valid, consumer generates and sends to merchant 

a 

DELIVERY_REQUEST message containing: Rc 
Step 4. 

a) Merchant receives DELIVERY_REQUEST and extracts Rc. 

b) Merchant computes TMP=H(Rc) and compares to H(Rc) stored in the 
appropriate transaction record. If there is no match, an error 
message to that effect is sent to consumer. 



c) If TMP matches H(Rc) merchant composes and sends to consumer, a 
DELIVERY message containing: 
GOODS, SKm SIG_commit,GOODS 

\ / 

SIG_deliver 

or, if PKtmp was included in COMMIT_REQUEST message (as in Step 1 
above), a DELIVERY message contains: 
PKtmp(GOODS), SKm SIG_COMMIT,GOODS 

\ / 

SIG_deliver 

where PKtmp(GOODS) denotes the encryption of GOODS under the 
consumer-generated public key PKtmp. 
(Only if PKtmp was included 
in COMMIT_REQUEST above.) 
Step 5. 

a) Consumer receives DELIVERY and, if applicable, decrypts 
PKtmp(GOODS) using SKtmp. (Otherwise, GOODS arrives in the 
clear.) 

b) Using PKm and SIG_commit (received in Step 3) consumer verifies 
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SIG_deliver. If SIG_deliver is invalid an error message to 

that 

effect is sent to merchant. 

Otherwise, consumer sends to merchant a TERMINATE message 
containing Rd. 
Step 6. 



a) Merchant receives TERMINATE, extracts Rd, computes TMP=H(Rd) 

d 

compares it with H(Rd) received in COMMIT_REQUEST (see step 2.) 
If they match the transaction is terminated. Otherwise, an 
error 

message is sent to consumer (perhaps along with the 
re-transmission of DELIVERY.) 

The method presented above provides protection against 
dishonest behavior by either merchants or consumers involved. 
Potential cases of cheating and disputes are addressed below. All 
cases require intervention of a mutually trusted off-line authority 
that we refer to as COURT. 



While dispute resolution is likely to take place off-line, it 
is expected that consumer will remain anonymous with respect to 
merchant. However, consumer may be required to reveal his identity 
to COURT. 

At the end of a successful transaction the parties involved must have 
the following in their possession: 

Rc, Rd, SIG__Commit, SIG_offer, H(Rc), H(Rd) 
Dispute Scenarios 

a) Customer is asked to produce a valid SIG_offer 

a. No valid SIG_offer; merchant prevails. 

b. Valid SIG_offer; continue with (2). 

b) Merchant is asked to provide Rc. 
a. 

Merchant can not produce the correct Rc; continue with (3). 
b. Correct Rc; continue with (4) 

c) Consumer is asked to produce Rc. 

a. Correct Rc; consumer prevails (protocol can be re-run.) 

b. Incorrect or no Rc; merchant prevails. 

d) Consumer is asked to produce Rc. 

a. Correct Rc; continue with (5). 

b. Incorrect or no Rc; merchant prevails. 
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e) Consumer is asked to produce a valid SIG_commit. 

a. No valid SIG_commit; merchant prevails. 

b. Valid SIG_commit; continue with (6). 

f) Merchant is asked to produce Rd. 
a. Correct Rd; merchant prevails. 



b. Incorrect or no Rd; consumer prevails (merchant is ordered 
to send a DELIVERY message to consumer and consumer is 
ordered 

to reply with a TERMINATE message (the latter containing a 
valid Rd.) 
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[57] ABSTRACT 

Transactions are conducted on the Internet, by telephone or 
directly with anonymity and privacy. A customer's shipping 
address is encoded by a multi-digit identifier which is stored 
in the database of a trusted third party, preferably the 
shipping company. A user of the system need only identify 
themselves to a vendor by this multi-digit identifier which 
prints the identifier in machine readable form on a package 
delivered to the shipper. 

5 Claims, 4 Drawing Sheets 
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METHOD OF PROVIDING AN IDENTIFIER 
FOR TRANSACTIONS 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention generally relates to performing 
transactions with anonymity and, more particularly, to a 
method for providing a unique identifier for collectively 
electronically tagging personal data. 

2. Background Description 

People are hesitant to supply personal data for making 
transactions for fear of subsequently being placed on direct 
marketing mailing lists. This is particularly true in conduct- 
ing transactions over the Internet. If this step of providing 
name and address were replaced with a more anonymous 
identifier, perhaps more potential customers would engage 
in electronic transactions on the Internet. And for those who 
do, repeated transactions would be easier as they would only 
have to provide the one field. Such an anonymous identifier 
could also be used in other types of transactions as well, 
including telephone transactions and face-to-face transac- 
tions in a retail shop. 

In order to accomplish this, however, a third party iden- 
tifier supplier has to be a trusted part of the transaction. 
Many transactions requiring name and address information 
involve having a product shipped to a customer. The pro- 
vider of that service (e.g., U.S. Postal Service, UPS, Federal 
Express, or other carrier) could well provide a unique 
personal identifier for the customer. This same identifier 
could later be used as an additional means for tracking 
shipments made to the customer. Rather than using a new 
delivery identifier for each shipment, the customer could 
provide their personal identifier to track shipment. 

SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to provide 
a way to conduct transactions with anonymity and privacy. 

According to the invention, there is provided a method for 
identifying a customer's shipping address by a multi-digit 
identifier which is stored in the database of a trusted third 
party, preferably the shipping company. A user of the system 
need only identify themselves to a vendor by this multi-digit 
identifier which prints the identifier in machine readable 
form on a package delivered to the shipper. A further 
advantage of the invention is that if the customer moves and 
needs to change their address, they have but one place to do 
so. Hence, when conducting business with many vendors, 
one would not need to repeat their address to each vendor for 
each transaction, rather, all that needs to be provided is an 
address code. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and advantages 
will be better understood from the following detailed 
description of a preferred embodiment of the invention with 
reference to the drawings, in which: 

FIG. 1 is a schematic diagram showing the creation and 
use of a personal identifier throughout the course of a 
transaction according to the invention; and 

FIGS. 2 A, 2B and 2C, taken together, are a flow chart 
showing the logic of the system implementing the invention. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT OF THE INVENTION 

Referring now to the drawings, and more particularly to 
FIG. 1, there is shown, in s schematic diagram form, the 
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process of creation and use of a personal identifier for 
Internet transactions. When ordering a product over the 
Internet, one must supply to the vendor a shipment address. 
With this, the vendor can send the product to the customer 

5 using some existing delivery mechanism, such as the U.S. 
Postal Service, UPS, Federal Express, or the like. Also, with 
this information, the vendor can augment their mailing list 
and, possibly, sell it to other marketing firms. The purpose 
of this invention is to conduct the same transactions with 

10 anonymity, insuring the privacy of the customer. 

The method used in this invention is to employ a third 
party vendor to supply a unique identifier to the customer 
that maps to the customer's name and address in a database 
owned by the third party. The personal identifier is a 
15 multi-digit numeric or alphanumeric code assigned to a 
customer, as indicated at 10. This code is an accepted field 
by the vendor 12 that is used for shipping purposes. The 
— sapper J4is the creator and c ustodia n of the _codes, It 
f generates a unique code for each customer, which code is 
20 associated with the customer's mil shipping address and, 
optionally, the customer's name, permitting shipment to be 
made to the customer 16. 

The association is maintained as a private database by the 
delivery organization. The shipper has an agreement with 

25 the customer not to sell its database codes and addresses to 
outside marketing organizations. The shipper also has an 
agreement with vendors to use this code with all shipping 
requests. When the vendor sends a package to the shipper, it 
is sent with this code for processing. 

The process is illustrated in more detail in FIGS. 2 A, 2B 
and 2C, to which reference is now made. A transaction 
begins at block 201 with the user wanting a product that 
cannot be sent electronically, i.e., over the Internet. An initial 

35 dete rmination is made in decision blo ck 202 as to ^yfiethef*"" ^ 
,_the user has arjL.a ddress co de. If not/lne mailing address 
information is collected from the user in function block 203. 
Next, in function block 204, the registry is contacted to 
obtain an .address co de . This routlnels shown in more detail 

4Q in FIG. 2B and begins with validating the addressj nfu nction 
block 205. An address code is assigned in funcriorrblock 
206, and this code is saved in function block 207 to the 
shipping company's master file database 208 before a return 
is made in function block 209 to the main routine in FIG. 2 A 

45 where the code is displayed and saved to the user's computer 
in function block 210. 

Referring again to FIG. 2A, once the user has an address, 
code then a determination is made in decision block 211 as 
to whether the address code is available. If not, the user is 

50 prompted to enter the address code in function block 212; 
otherwise, the code is directly retrieved from the user's hard 
disk in function block 213. The address code is added to the 
order form in function block 214, and the order is submitted 
in function block 215. 

55 Referring now to FIG. 2 C, when the vendor receives the 
order, the vendor optionally creates^ printed, machine 
readable represent ationjof_ the addressjsodejo n the^ shipping 
lab eT*irTfunc tion b lock 216 . ThVaHdress code is printed to 
'^n'lrie'shipping label in function block 217, and the package 

60 is sent to the shipping company in function block 218. The 
shipping company uses the machine readable address code 
printed on the shipping label to access the master file 208 
(FIG. 2B) to retrieve the user'shipping address for delivery, 
of the package. v "~~* 

65 The benefits to the vendor is that more customers will be 
more likely to participate in their electronic marketplace if 
they only need to provide their multi-digit identifier instead 



11/03/2003, EAST Version: 1.4.1 



6,006,200 



of their name and address. Thus, the vendor does not know 
their customer's identity, only their preference for one of 
their products. The benefit for the delivery agent is that the 
vendors will be more inclined to choose them for delivering 
packages. The benefit for the customer is that a level of 
anonymity is established for the transaction. 

While the invention has been described in terms of a 
single preferred embodiment, those skilled in the art will 
recognize that the invention can be practiced with modifi- 
cation within the spirit and scope of the appended claims. 

Having thus described our invention, what we claim as 
new and desire to secure by Letters Patent is as follows: 

1. A method of conducting transactions while preserving 
the anonymity and privacy of a user comprising the steps of: 

assigning to a user a multi-digit identifier which is stored 
in a master file database of a trusted third party; 



to 



15 



using by a customer the multi-digit identifier to order a 
product; 

printing by a vendor the multi-digit identifier on a pack- 
age to be delivered to the customer, and 

accessing the master file database by a shipper to obtain 
the customer's shipping address. 

2. The method recited in claim 1 wherein the master file 
database is owned by the shipper. 

3. The method recited in claim 1 wherein the multi-digit 
identifier is printed in machine readable form. 

4. The method recited in claim 1 wherein the product is 
ordered on the Internet. 

5. The method recited in claim 1 further comprising 
notifying by a customer a change of address to the trusted 
third party in order to effect a change of address. 
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